A virtual LAN (“VLAN”) is a group of networked devices that are in a separate broadcast domain even though they share a physical medium with other networked devices which do not belong to the VLAN. For example, a virtual LAN may comprise a number of LAN segments which are on different ports of a switch. Data may be carried between segments of a virtual LAN over connections in a shared network. The shared network may operate according to a networking protocol different from that of the network segments. For example, two segments of an ethernet network may be connected by a connection in an asynchronous transfer mode (ATM) network. Each of the network segments may be interfaced to the shared network by a bridge.
IEEE standard 802.1Q provides a set of capabilities which permit media access control (MAC) bridges to define and manage virtual LANs. IEEE standard 802.1D describes the operation of MAC bridges. In this disclosure the term “VLAN” is not limited to VLANs which operate according to the IEEE 802.1Q or 802.1D specifications.
A typical bridge comprises a plurality of bridge ports. The bridge receives data frames at its bridge ports. The bridge has access to a forwarding database (the forwarding database is sometimes called a “filtering database”) which associates the addresses of various devices with specific ones of the bridge ports. When the bridge receives data addressed to a specific destination address at a bridge port, the bridge looks up the destination address in the forwarding database. If there exists an entry in the forwarding database which associates the destination address with a bridge port then the bridge determines whether the bridge port associated with the destination address is the same bridge port at which the data was received. If so, the bridge may discard the data. Otherwise the bridge forwards the data to the bridge port identified in the forwarding database. If there is no entry for the destination address in the forwarding database then the bridge may forward the data to multiple bridge ports (this is sometimes called “flooding” the bridge ports) so that the data can reach its destination.
A bridge is typically configured to build a forwarding database dynamically. When the bridge receives data at a bridge port it inspects the data for a source address (bridges which operate according to 802.1Q and/or 802.1D typically inspect the data for the MAC address of the device at which the data originated). If the bridge can ascertain a source address for the data then the bridge may automatically create in the forwarding database an entry which associates the source address with the bridge port at which the data arrived at the bridge. If there is an existing entry in the forwarding database which associates the source address with a different bridge port then the bridge may update the existing entry to associate the source address with the bridge port at which the data arrived at the bridge.
The 802.1Q specification provides for two different types of forwarding database. One type of forwarding database, called a shared forwarding database, is shared between multiple VLANs. The specification also describes a second type of forwarding database called an “independent forwarding database”. Where a bridge uses independent forwarding databases, a separate forwarding database is provided for each VLAN. Providing a separate forwarding database for each VLAN provides flexibility but imposes more stringent hardware requirements. Each forwarding database requires significant memory and other resources.
Data which belongs to a VLAN may be tagged to identify the fact that the data belongs to the VLAN. A VLAN tag may comprise, for example, a field in the header of a data frame. The tag may, for example, comprise a few bits which identify a VLAN ID number (“VID”). It is sometimes necessary for devices in a VLAN to send data to or receive data from a device which is not VLAN-aware. It can be necessary to remove the VLAN tag to provide an untagged data frame before sending data to such devices.
Bridges which have shared filtering databases, as described above, cannot be used effectively in cases where a single non-VLAN-aware networked device may be required to exchange data with other devices which belong to multiple VLANs. Where traffic for each of the VLANs is carried on a different set of the bridge ports, the non-VLAN-aware device may send data to more than one port of the bridge. This causes problems because each time the device sends data to a different one of the bridge ports the bridge updates its shared forwarding database to associate the device with that bridge port. A filtering function on each bridge port could be used to determine the correct VLAN for data packets received at that bridge port. Such a filter would, for example, snoop ethernet packets for specific information such as IP address, UDP port, etc. Such filters are expensive to implement because extra data in every frame must be read. Depending on the nature of the attached device, such a filter may still fail to identify the appropriate VLAN.
U.S. Pat. No. 6,137,797 describes a device for interconnecting local area networks. The device has ports for attaching LAN segments and port modules for connecting the ports to a switch fabric. Each of the port modules includes a mechanism for identifying a port through which a received frame is to be routed by searching a routing information field of the received frame.
There is a need for cost effective methods and apparatus for routing ethernet frames to virtual LANs. There is a particular need for such methods and apparatus which permit an end station having a single address to exist on multiple bridge ports which belong to separate VLANs.